package md.specialEqp.inspect;
//先有旧的数据，才再去搞的enum定义，数据库DB存储用Byte 1个字节/数字

/**报告出具的过程环节。 Report状态值 9个状态值形式。
一般的申请单，请求批准应用场景的，是审批通过或者审批不通过都会END。
 所以一般简单的申请状态组合是【 MAKE正在申请当中, APPR提交给审批人 ,END审批完成, CANCEL取消 】就能应付需求。
 ISP流程环节CURR_NODE= [1=初始, {id:'101',text:'报告编制'},{id:'102',text:'责任工程师审核'}, {id:'104',text:'负责人审批'},
 {id:'105',text:'文印室打印'[制作证书报告?报告归档清单]},{id:'106',text:'终结'[终结后才发放报告证书?]} ,{id:'107',text:'注销'}];
 等待整改反馈CURR_NODEID: "103";{分项报告多出的103独立审核情况,[子报告审核通过103状态]主报告还是101状态}
 整改反馈期内的不合格报告不能直接送审批104, 子报告分项也不能直接送审批=需要组合103整个报告/主报告才能送审批。
 也能做成普通申请单的审批流程，甚至投票器应用。
 所有单子都是MAKE开始，END结束。
 【特别注意】这个enum的数值顺序从0开始，数据库实际存储就是这些序号整数的。所以除非人工重整整个表；否则不允许在中间插入新的enum项目，只能末尾添加也不能删除项目。
 关系数据库存储Procedure_Enum类型字段的缺点：改成字符串存储？ ES没这问题。
 */

public enum Procedure_Enum {
    /**待初始化，空报告，等待zeebe流转；
     * 状态机新生成，未投入使用。   #报告参数还未设定，未初始化，等待选择报告模板以及版本号。等待真正初始化启动；
     * 这个特殊零状态，必须由关键控制人master开启运作，才能流转。
     * 设置BEGIN可不需要记录流转{必然是master某时刻去开启的无需记载}。
     * */
    BEGIN,

    /**回退 再次进入编制修改报告； 类似BEGIN，只是后退撤出的结果。
     * 报告编制阶段，在填写申请单；原始记录录入，签名，下结论,  # 报告编制进行当中的，或退回到了编制。等待编制录入以及下检验结果结论；
     * 复检等待？ 需要复检的可能驻留本状态环节？ 单独标记状态还是 合并一个字段就能表达了。
     * 复检派工后负责人选择那些报告/子报告需要重新进入编制阶段
     * 复检相当于重置，但是旧的流程记录保留。
     * 主报告子报告可以前端一个按钮一起流转审核，但是子报告必须全部审核通过了后主报告才能允许审核通过。
     * 各种申请单子的新生成初始状态=正在填写申请单。
     * 报告校核人才能流转签名环节(节点 CurrentNode)。通知检验人员签字确认。
     * 下结论，报告不能再修改；流转签字，开始可以签。
     * 校核人流转签字，Circulation.moreUser会保留编制阶段的所有检验员(可能包括校核人);
     * 报告校核人也要签名，检验员authr必然包含校核人。
     * 复杂节点; 特别权利人=校核人
     * */
    MAKE,

    /**校核人通过zeebe流转进入会签环节。代表进入到了签字环节了 但可能某个人尚未签字。zeebe自己有状态，我这只能大概说明刚刚经过某个环节的处理，方便追踪。
     * 签字环节： #报告下结论之后的状态  #流转点击之后，进入zeebe流程服务的管辖范围了。提交签字，多人会签。
     * 每个检验员都要对报告结论内容的真实性进行签字；流转签字后不能修改报告，
     * 每个人都要签字同意，签名投票通过原则达成的可流转下一个节点，投票结果可以赞成也能反对的也算终结了，
     * 没达成的由主持人可回退，票数不够原因撤回投票的。
     * 签字环节最后一个人提交签名后触发消息通知会议主持人，都已经签了，校核人可以流转审核了。
     * 校核人若在最后一个签[其他人差需要投票]，直接就能一并触发流转CHECK审核，可省事(没必要发消息或记录)。
     * 校核人master获知所有人都签了，有反对意见的回退编制，一致通过的流转CHECK。
     * 报告签字反对意见=拒绝签字。
     * 最终校核人master流转审核，Circulation.moreUser会保留签字开始前的所有需签名的User;
     * 复杂节点; 特别权利人=校核人
    */
    SIGN,

    /**责任工程师 审核阶段，报告内容结论的审查， 收费清单和发票； #会签完成通过的，等待责任工程师审核节点。
     * 子报告可单独流转审核。
     * 子报告审核通过了 流程结束；
     * 主报告核通过了 流转去审批环节。
     * 子报告 审核通不过退回编制，或者直接流转等待复检。
     * 主报告 审核通不过退回编制，或者直接流转等待复检, 下个环节人员=派工的负责人。
     * 子报告都要优先审核，流转不合格复检前需要搞清楚那些子报告也需要复检，子报告都能通过了吗。
     * 主报告流转审核时要保证所有子报告都已流转审核，
     * 主报告流转复检或审批都要首先确定所有子报告的状态兼容性。
     * 审核环节直接退回报告编制节点：[签字投票节点没必要做单独退回的节点]。
     * */
    CHECK,
    /**等待复检， 检验业务的工作部分重做。        #？？     扩展状态：其它接口流程申请后重新进入报告编制环节。
     * 负责人可以 重新派工,派工可选择那些主子报告需要重新进入报告编制阶段
     * 主报告 子报告 都可以进入本阶段。
     * 等着重新派工。
     * */
    WAITREDO,

    /**审批阶段， 关注发票和回款进度(是否允许发放报告，证书能不能给客户了，允许产品交付)，  #责任工程师审核通过的，等待上级的审批节点。
     * 审批好 允许进入下一阶段是 制作证书报告 报告归档
     * 子报告没有这个阶段。
     * */
    APPR,

    /**报告证书发放 文印室打印阶段, 产品交付进行中；       #？？
     * 档案归档 报告和证书打印和盖章 ，报告和证书已发放
     * 子报告没有这个阶段。 报告已经组合了。
     * */
    OFFER,

    /**报告流转完成了；终结, 所有的业务审批申请单 或 报告最后都需要到达这个状态。  #报告流转顺利完结，报告已经可以给客户查看了。
     * 主报告报告和证书已发放完成，
     * 等待关联任务上做终结(收费回款是Task合同的事情)；
     * 子报告不能独立对外提供，对外部接口只能是主报告。
     * 主报告和子报告END状态指示的含义可能不同。
     *子报告单独审核通过； 并流转组合 等待组合 等待与主报告组合和审核103，子报告分支流程结束！
     * 子报告单独审核通过了流程结束，复检若不指定特定子报告重新编制，旧的审核依然有效。
     * */
    END,
    /**注销 作废 等待物理上删除             #报告流转终结但是非正常的流程出口。
     * 子报告也可单独做 注销 删除
     * */
    CANCEL;
}




/*
当前流程节点;
    状态转移关联记录模式。Auditflow 业务含义阶段状态 status，
子报告只有两步操作，流转单独审核{审核人员自选不是派工时刻就指定的审核人}，单独审核不通过回退编制{派工时检验员多人}，单独审核通过并流转组合{子报告分支流程结束}；
 子报告特有环节= 等待与主报告组合和审核103。
有不合格结论导致并且需要复检的情况， 流转102审核通过后[允许不合格复检]有个复检任务再做派工？{Task任务状态修订},流转复检环节103;复检后再次101编制？
 等待整改反馈期内的复检不收费，过了之后要收费。复检判断 如果复检派工的时间小于等待整改反馈期，则取原来的报告号=Isp；
 等待整改反馈期内的复检就不需要Task终结了再派工另外一个新的Task(初次检验未能通过的部分设备),直接对未终结Task重复派工(任务标记复检，等待复检的设备，部分Isp终结)。
 并流转到责任工程师组合,再由主报告带着一起流转审核(子报告分解目的已经结束)；主报告和分项报告节点status不一致错误;
 报告签发了终结，异常可注销。
 复检环节标记。
报告签字的不可抵赖性的保障：
web报告签字， Pdf自带签名。
 实际算报告流转的中间新节点：所有的检验人员都要签字流转到校核人,，缺一人不可，校核人 流转审核节点。
 */

